So this is what happens when I try to run Perl on Windows.
1. Get a crazy idea about cross-compiling everything on Linux so I don't have to use the qdos shell.
2. Read way too much of the Alien::wxWidgets Module::Build-based build system.
3. Create a forced-filled Alien::wxWidgets config (the build system won't do it and is probably way too complicated for what it does do or at least doesn't do a good job of letting you build your own wxWidgets.)
4. Read way way way too much of the Wx MakeMaker-based build system.
5. Run away screaming from that.
6. Forray into switching random distros to Module::Build (e.g. Scalar-List-Utils) -- discover bug in ExtUtils::CBuilder WRT extra_compiler_flags being dropped on the floor.
6a. $self->fork && $self->explore_inadequacies_of_cygwin()
6b. $self->fork && $self->read_way_too_much_of("the perl Core's build system")
6c. $self->fork && $self->realize("parrot may never cross-compile either")
7. Find EU::CB bugs in the M::B tracker.
8. Realize M::B tracker is crazy full.
9. Track down weird .packlist bug involving M::I, EU::MM, M::B and ExtUtils::Installed, realize there is no documented behavior for this and work with Adam to invent one.
10. Realize M::B tracker is still crazy full and run away screaming.
Well, really -- I'm not a screamer. I am pretty overwhelmed, my eyes are bleeding, and I've typed "local $^O = 'MSWin32'" far too many times in the last several days.
The Module::Build documentation needs to be almost completely restructured.
ExtUtils::CBuilder probably needs a big refactoring, but getting test coverage for that on all supported platforms is no small feat.
ExtUtils::MakeMaker will have a hard time ever supporting cross-compilation and even given ExtUtils::CBuilder's cleaner design it will still be a *lot* of work.
Wx::build::MakeMaker needs to go away and Alien::wxWidgets needs to be seriously simplified.
And yes, there's a PAR tie-in.
And no, I don't have all the answers. I don't even have time to read all of the code involved. I don't even have time to read all of the bugs in the tracker.
Most authors don't understand how all of this fits together, so they do a lot of extra work and frankly create a lot of buggy build code to try to accomplish what should be fairly simply supported by the toolchain. If you don't believe me, go read a few Makefile.PL's, or even Build.PL's.
Only a few people are involved in all of this toolchain stuff and most of them are not adequately compensated for the huge amount of work they do (particularly given that it is hugely important.)
I still don't have a good solution.
Better documentation? Some kind of QA effort that targets a distro's build code?
And, for now, I'm out of time too.
Re:Yum, Strawberry
Eric Wilhelm on 2007-07-17T05:46:59
Yeah, I'm using Strawberry. As "Perl on Windows" goes, it's very good. But underneath, Windows is still just qdos masquerading as an operating system. Maintenance is a hassle, development is a hassle, everything is a hassle.
The basic point is that I don't want to be running windows, not even to build my code. Every...Single...Thing about it is an impediment. I'm guessing that I'm not totally alone in thinking there's a better way to do it that doesn't involve rebooting. Note that most open source C/C++ projects build without a hitch running mingw32 on linux (including wxWidgets, Mozilla, etc.) Yes, Linux has better tools available even for building Windows code. I'm even thinking of running the tests on wine. If nothing else, exporting the built dir with samba would certainly take care of the issue where I have to reboot after running CPAN so that the system can *copy a file*!
5. Run away screaming from that.
You realize that, reading that,
this is what I'm hearing.
